Sisällönhallintajärjestelmistä

Olen työ- ja harrastusurani aikana kokeillut hyvin montaa erilaista sisällönhallintajärjestelmää. Termi sinänsä on hyvin laaja ja niin on ollut myös kirjo järjestelmistä, joita olen käyttänyt. On ollut toiminnaltaan suoraviivaista ja abstraktimpaa, laajennettavuudeltaan rajoitettua ja lähes rajoittamatonta sekä käyttöliittymältään hyvää ja huonoa. Ja järjestelmät ovat olleet sekä avoimen lähdekoodin järjestelmiä että kaupallisia. Kaikki ovat olleet jossakin hyviä. Ainakin niiden kehittäjien mielestä.

Paljastettakoon tässä vaiheessa että minä olen viimeiset pari vuotta käyttänyt Modx-nimistä avoimen lähdekoodin järjestelmää. Tämä blogintapainenkin pyörii sen päällä. En ole mitenkään erityisemmin naimisissa tämän alustan kanssa mutta aikanaan piti valita joku jota käyttää ja tämä oli vähiten hankala. Nykyisessä työssäni en kuitenkaan ole päässyt toteuttamaan sisäistä open source hörhöä vaan käytän suljettua kolmannen osapuolen järjestelmää. Mutta takaisin aiheeseen.

Kaikki järjestelmät, joita olen käyttänyt ovat olleet tietyllä tapaa hankalia käyttää tehokkaasti. Tai lähestyminen on jotenkin nurinkurinen. Tiedättekö, jotta minä voisin muuttaa tätä sivua on minun ensin kirjauduttava sisälle, mikä on toki ymmärrettävää. Tämän jälkeen siirryn vallan erinäköiseen “ympäristöön”, järjestelmän backendiin hakemaan muutettavaa sivua.Kun vihdoin sen löydän, ja väliin jo tämä on saavutus, pääsen muuttamaan sivua. Tämän jälkeen tulee tallennus, mahdollisesti esikatselu ja julkaisu. Eikö se suurinpiirtein noin mene joka järjestelmässä?

Rami ja Make

No ajatellaampa naapurin Ramia tässä. Rami on erittäin pätevä automekaanikko. Viime kesänäkin purki sen 140 Y Datsunin ja syksyyn mennessä se oli maalattuna ja ajokunnossa. Lyhyesti sanottuna Rami on aika perusjamppa tällaisten järjestelmien kanssa. Osaa käynnistää tietokoneen ja Internet on Sininen. Rami on kuitenkin ostanut omalle yritykselleen nettisivut. Kuinka vieras tällainen prosessi on hänelle. Ramilla on wöördi, jossa tiedoston muokkaus tapahtuu siinä kohdalla, jossa tiedosto on. Tämän verran hän tietää ennen kuin saa järjestelmän eteensä.

Jotta Rami osaisi käyttää järjestelmää, täytyy sen olla yksinkertainen. Ja helppo. Niinpä järjestelmä tulee suunnata Ramin tapaisille käyttäjille. Tässä meillä tulee kuitenkin esiin pieni ongelma, johon olen törmännyt monen järjestelmän kanssa. Tällainen yksinkertaistaminen luo järjestelmään yhden tason lisää. Jatketaan ajatusleikkiä hieman toiselta suunnalta.

Rami on tilannut sivustonsa oikein Mainostoimistosta. Mainostoimiston myyntimies kehui kovasti ja heittipä mukaan kaikennäköisiä hienoja ideoita joistakin ihmeen hakukoneista ja muista. Ja hyvännäköiset kuvat sieltä tulikin. Mainos-Make, raskaan sarjan web develoopperi, on vastuussa Ramin sivujen rakentamisesta. Jotta Make saisi rakennettua sivut mahdollisimman kustannustehokkaasti on hänen pystyttävä tekemään toteutuksia lähes vapain käsin. Ongelma vain on se, että järjestelmä jota käytetään on samannäköinen sekä Makelle että Ramille.

Järjestelmäkehittäjän näkökulmasta tilanne on hankala. Toisaalta loppukäyttäjille pitää tarjota vain se, mitä he tarvitsevat. Ja vielä oikeastaan rajata sitä aavistuksen kapeammaksi, jotta mikään ei menisi rikki. Taasen web developerille pitäisi pystyä tarjoamaan mahdollisimman esteetön työympäristö, jotta hän voisi rakentaa laadukkaita sivuja omalla työtavallaan. Miten tällainen tilanne sitten saataisiin aikaiseksi?

Ylläpito ja sisältö erilleen

Järjestelmästä pitäisi erottaa ylläpidollinen puoli ja sisällöllinen puoli. Mitä tämä käytännössä tarkoittaa? Kyse on yksinkertaistettuna samasta asiasta, missä html:n ja css:n erottamisessa tai MVC-koodauksessa on kyse. Asioiden erottamisesta kontekstin mukaan. Käyttäjien tulee päästä muokkaamaan sivuja suoraan siitä missä sivu on, eli frontendissä. Ylläpitäjille tai kehittäjille annetaan vapaammat kädet backendin puolella eikä kaikkia toimintoja tarvitse automatisoida tai kääriä graafiseen käyttöliittymään.

Suurin osa käyttäjän syöttämästä informaatiosta olisi joka tapauksessa mahdollista syttää suoran frontendista. Sivut, uutiset, blogit, kuvagalleriat, videot. Tämäntyyppisiä ratkaisuja on maailmassa paljonkin. Ja kokemus käyttäjälle olisi tuttu ja helppo. Facebook toimii näin, Squarespace toimii näin ja ilmeisesti Plone toimii näin. Osaan järjestelmistä on mahdollista liittää laajennos, joka mahdollistaa tämän. Modx:n mukana tuleva QuickManager-plugin tarjoaa tällaisen mahollisuuden, käsittääkseni Joomlassa on samantyyppinen ominaisuus ja Drupal tarjoaa tämälaisen ominaisuuden myös.

Ylläpito ylläpitäjille ja kehittäjille

Nyt kun on saatu loppukäyttäjä backendistä pois, miten siitä tehtäisiin sitten kehittäjän työkalu. Yksinkertaisesti riisumalla se ylimääräinen “helppouden” kerros. Graafiset kliketiklik-toimiset naputinap-hiiri”työ”kalut pois ja tilalle yksinkertaisia komentoja. Järjestelmänlaajuisia komentoja. Minä haluan valikon tähän, miten se tapahtuikaan. Ainiin joo, [Menu]. Mukaan järjestelmänlaajuiset moduliulkoasut, jolloin se valikon muotoilukin olisi helppoa. Mitenkä se menikään, ai joo [Menu tpl=‘ultimate-menu-tpl’]. Miten ne sivut saatiin nyt listattua tähän fiksusti pienen ingressin kanssa, ootappas [Pagelist tpl=‘pagelist-with-ingress’ parent=‘12’ level=‘1’]. Lomake tonne, [Form tpl=‘contact-form’ saveindb=‘true’ sendto=‘[email protected], [email protected]’]. Hoksaatte varmaan mitä ajan takaa.

Tässä vaiheessa joku varmasti huomauttaa että “ei tuollaisessa rumassa ympäristössä voi toimia kuin joku nörtti koodari”. Tunnustan, olen nörtti koodari. Ei pelkistetty ympäristö ole välttämättä ruma. Esimerkkejä löytyy vaikkapa OS X:n ulkoasusta. Siinä grafiikka on niin pelkistetty että se häipyy pois edestä ja mahdollistaa tehokkaan työskentelyn. Ja huomatkaa, että kun puhun graafisten kilkkeiden poistamisesta en tarkoita grafiikan ja käyttöliittymän poistamista. Mielestäni hyvä käyttöliittymä mahdollistaa tehokkaan työskentelyn. Ja hyvä käyttöliittymä tarkoittaa eri asiaa kehittäjällä ja loppukäyttäjällä.

Toinen kommentti jonka kuulen menee suurinpiirtein näin “ei noita tuollaisia kryptisiä yhdistelmiä voi muistaa ulkoa”. Totta. Minä olen todella huonomuistinen tällä hektellä töissä käyttämäni järjestelmän komentojen kanssa. Siltikin kaikki käyttämäni järjestelmät ovat vaatineen noita kryptisiä tageja, ainakin rakennusvaiheessa. Tällaiset tagit vaativat dokumentaatiota, riittävää dokumentaatiota jotta niitä voi käyttää ennenkaikkea tehokkaasti. Dokumentaation ei tarvitse olla laaja, kunhan se on riittävä. Tämä on haaste monessa järjestelmässä, joita olen käyttänyt. Eivätkä nykyiset tee poikkeusta. Itseasiassa on ikävä myöntää mutta Modx:ssä taitaa olla parempi dokumentaatio kuin päätoimisesti käyttämässäni järjestelmässä.

Tästä tuli hieman pidempi postaus kuin olin ajatellut joten jätetään järjestelmien kehittäminen tähän. Lisää ideoita olisi vielä mutta epäilen että osa lukijoista on jo lopettanut lukemisen. Kiitos sinulle, jos jaksoit lukea loppuun.